Fix make secrets-init — SOPS matches creation rules on the input path - #6

Reported from a real run on the monitoring host:

    -- creating observability.sops.yaml from the template
    error loading config: no matching creation rules found
    make: *** [Makefile:62: secrets-init] Error 1

SOPS selects a creation_rule by matching path_regex against the *input* path.
The script encrypted the template and redirected the output:

    sops --encrypt secrets/observability.example.yaml > secrets/observability.sops.yaml

so SOPS tested `secrets/.*\.sops\.ya?ml$` against the **example** filename,
which does not end in .sops.yaml. No rule matched. The output name is never
consulted, so the destination being correct made no difference.

Copy to the destination name first, then encrypt in place, which is the path the
rule actually targets.

Two guards added, because the failure mode of getting this wrong is worse than
an error message. `cp` followed by a failed encrypt leaves a plaintext file
sitting at a path whose name says "encrypted" — and it is not gitignored,
because encrypted secrets are meant to be committed. So on any encryption
failure the partial file is removed, and success is confirmed by checking for
the `sops:` metadata block rather than trusting the exit status. CI catches a
plaintext secrets file, but only after it has been pushed.

This was never caught because the whole path needs an age key, and the earlier
work stopped at "cannot verify without the user's key" rather than generating a
throwaway one.

Verified end to end in a sandbox with its own HOME and a disposable keypair:

  1. bootstrap produces a genuinely encrypted file — keys readable, values
     ENC[AES256_GCM...], no placeholder text remaining
  2. `sops --encrypt --in-place` round-trips after editing values
  3. render-config.sh writes snmp.yaml, webhook_url and .env
  4. a community containing / & \ and $ renders byte-for-byte intact, and all
     four devices keep distinct values
  5. no SNMP community reaches .env — only the two values compose interpolates
  6. `docker compose config` passes against the real rendered .env
  7. git sees only .sops.yaml and the encrypted secrets file as stageable; no
     .env, .rendered/ or plaintext copy can be committed

…ecks

Review feedback, and correct: cleanup only covered the two failures explicitly
checked. Between the `cp` and a verified encryption the file is plaintext at a
path that is meant to be committed and whose name says "encrypted" — and it is
deliberately not gitignored, so anything leaving it behind is a leak waiting to
be committed. A chmod failure under `set -e`, a Ctrl-C mid-encrypt, or a SIGTERM
all skipped the rm.

A trap on EXIT INT TERM is now armed immediately after the cp and cleared only
once the sops metadata block is confirmed present.

Verified in an isolated sandbox with its own HOME and a disposable keypair:

  * happy path still produces an encrypted file
  * a broken age recipient leaves nothing behind
  * SIGINT delivered to the script's own process group mid-encrypt — a real
    Ctrl-C — leaves nothing behind: present before the signal, absent after

Three earlier attempts at that last test were inconclusive rather than passing,
which is worth recording because each one looked like a result:

  * signalling a process group that, in a non-interactive shell, also contained
    the test harness
  * sending SIGINT to the script's pid, where bash defers the handler until the
    foreground command returns — sops completed and the file legitimately
    survived encrypted, which reads as a leak unless you check the contents
  * a setsid run whose $! had already exited, so the kill addressed an empty
    pgid and no signal was ever sent

Only the setsid + pgrep-resolved pgid version actually exercises the path.